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(54) Secure mutual network authentication and key exchange protocol 



(57) Secure communication protocols are disclosed 
in which two parties generate a shared secret which may 
be used as a secure session key for communication be- 
tween the parties. The protocols are based on Diffie- 
Hellman type key exchange in which a Diffle-Heltman 
value is combined with a function of at least a password 
using the group operation such that the Diffie-Hellman 
value may be extracted by the other party using the in- 
verse group operation and knowledge of the password. 
In one embodiment each of the parties explicitly au- 
thenticates the other party, while in another embodi- 
ment, the parties utilize implicit authentication relying on 
the generation of an appropriate secret session key to 
provide the implicit authentication. Typically, the parties 
will be a client computer and a server computer. In ac- 
cordance with other embodiments of the invention, in 
order to protect against a security compromise at the 
server, the server is not in possession of the password, 
but instead is provided with, and stores, a so-called 
password verifier which is a function of the password 
and where the password itself cannot be determined 
from the value of the password verifier. 
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Description 

Field of the Invention 

5 [0001] The present invention relates generally to network authentication and key exchange. More particularly, the 
present invention relates to a password-only secure mutual network authentication and key exchange protocol. 

Background of the Invention 

10 [0002] Authentication over a network is an important part of security for systems that allow remote clients to access 
network servers. Authentication is generally accomplished by verifying one or more of the following: 

something a user knows, e.g. a password; 

something a user is, i.e., biometric information, such as a fingerprint; and 
15 something a user has, i.e., some identification token, such as a smart-card. 

For example, an automatic teller machine (ATM) verities two of these: something a user has, the ATM card, and some- 
thing a user knows, a personal identification number (PIN). ATM authentication is significantly easier than authentication 
over a data network because the ATM itself is considered trusted hardware, such that it is trusted to verify the presence 

20 of the ATM card and to transfer the correct information securely to a central transaction server. 

[0003] In addition to authentication, key exchange is an important part of communication across a data network. 
Once a client and server have been authenticated, a secure communication channel must be set up between them. 
This is generally accomplished by the client and server exchanging a key, called a session key, for use during com- 
munication subsequent to authentication. 

25 [0004] Authentication over a data network, especially a public data network like the Internet, is difficult because the 
communication between the client and server is susceptible to many different types of attacks. For example, in an 
eavesdropping attack, an adversary may learn secret information by intercepting communication between the client 
and the server. If the adversary learns password information, the adversary may replay that information to the server 
to impersonate the legitimate client in what is called a replay attack. Replay attacks are effective even if the password 

30 sent from the client is encrypted because the adversary does not need to know the actual password, but instead must 
provide something to the server that the server expects from the legitimate client (in this case, an encrypted password). 
Another type of attack is a spoofing attack, in which an adversary impersonates the server, so that the client believes 
that it is communicating with the legitimate server, but instead is actually communicating with the adversary. In such 
an attack, the client may provide sensitive information to the adversary. 

35 [0005] Further, in any password based authentication protocol, there exists the possibility that passwords will be 
weak such that they are susceptfole to dictionary attacks. A dictionary attack is a brute force attack on a password that 
is performed by testing a large number of likely passwords (e.g. all the words in an English dictionary) against some 
known information about the desired password. The known information may be publicly available or may have been 
obtained by the adversary through one of the above described techniques. Dictionary attacks are often effective be- 

40 cause users often choose easily remembered, and easily guessed, passwords. 

[0006] There are various known techniques for network authentication. These known techniques will be divided into 
two classifications. The first classification includes those techniques that require persistent stored data on the client 
system. The second classification includes those techniques which do not require persistent stored data on the client 
system. 

45 [0007] With respect to the first classification, persistent stored data may include either secret data (e.g. secret keys 
shared with the authenticating server) which must never be revealed, or non-secret but sensitive data (e.g. the au- 
thenticating server's public key) which must be tamper-proof. With either type of persistent data, extra security require- 
ments are necessary to secure the data from attack from an adversary. Further, when using an authentication protocol 
which relies on both passwords and persistent stored data, a compromise of either may lead to a vulnerability of the 

so other. For example, compromising a secret key may lead to a possible dictionary attack on the password. Another 
problem with this first class of protocols is that persistent stored data requires generation and distribution of keys, which 
can be cumbersome, and generally provides a less flexible system. 

[0008] The second classification is called password-only authentication protocols because there is no requirement 
of persistent stored data at the client. The client only needs to be able to provide a legitimate password. The notion of 

6 providing strong security and authentication using potential ry weak passwords seems to be contradictory. However, 
there exist several password-only user authentication and key exchange protocols that are designed to be secure. A 
description of these protocols may be found in D. Jablon, Strong Password-Only Authenticated Key Exchange, ACM 
Computer Communication Review, ACM SIGCOMM, 26(5):5-20,1 996. Some of the more notable of these password- 
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only protocols includes Encrypted Key Exchange (EKE) described In S.M. Bellovin and M. Menritt, Encrypted Key 
Exchange: Password-Based Protocols Secure Against Dictionary Attacks, Proceedings of the IEEE Symposium on 
Research in Security and Privacy, pp. 72-84, 1992; Augmented-EKE (A-EKE), S.M. Bellovin and M. Merritt, Augmented 
Encrypted Key Exchange: A Password-Based Protocol Secure Against Dictionary Attacks and Password Fife Compro- 

5 mise, Proceedings of the First Ann ual Conference on Computer and Communications Security, 1 993, pages 244-250; 
Modified EKE (M-EKE), M. Steiner, G. Tsudik, and M. Waidner, Refinement and Extension of Encrypted Key Exchange, 
ACM Operating System Review, 2922-30, 1995; Simple Password EKE (SPEKE) and Dlffie-Hellman EKE (DH-EKE), 
both described in D. Jablon, Strong Password-Onty Authenticated Key Exchange, ACM Computer Communication 
Review, ACM SIGCOMM, 26(5):5-20,1996; Secure Remote Password Protocol (SRP), T. Wu, The Secure Remote 

to Password Protocol, Proceedings of the 1 998 Internet Society Network and Distributed System Security Symposium, 
pages 97-111 , 1998; and Open Key Exchange (OKE), Stefan Lucks, Open Key Exchange: How to Defeat Dictionary 
Attacks Without Encrypting Public Keys, Security Protocol Workshop, Ecole Normale Sup^erieure, April 7-9, 1 997. 
[0009] The problem with these known password-only authentication protocols is that they have not been proven 
secure. In fact, the EKE protocol may be susceptible to certain number theoretic attacks as described in S. Patel, 

15 Number Theoretic Attacks on Secure Password Schemes, Proceedings of the IEEE Symposium on Research in Se- 
curity and Privacy, pages 236-247, 1 997. In view of the importance of network security, there is a need for a password- 
only mutual authentication protocol which is provably secure. 

[0010] Commonly assigned U.S. patent application serial no. 09/353,468 entitled Secure Mutual Network Authenti- 
cation Protocol, filed July 1 3, 1 999, discloses a secure password-only mutual network authentication protocol utilizing 
20 a public key encryption scheme. That protocol has been proven as secure as the underlying public key encryption 
scheme. 

Summary of the Invention 

25 [0011] The present invention provides a secure password-only mutual network authentication protocol which isprov- 
ably secure. In accordance with the inventive protocol, two parties generate a shared secret using a Diffie-Hellman 
type key exchange. As will be described in further detail below, in accordance with a Diffie-Hellman type key exchange, 
there is a group generator pfor the particular so-called group, an index x known to one party, an index y known to the 
other party, and the shared secret p*x. One party generates p* the other party generates pT, and the parties exchange 

30 these values so that each party may now generate the shared secret g*y. While Diffie-Hellman defines a key exchange 
protocol, the protocol has no authentication aspects. 

[0012] In accordance with the present invention, we provide a protocol which uses a Diffie-Hellman type shared 
secret, but modified such that the two parties may authenticate each other using a shared password. Further, and 
importantly, we have proven that this protocol is secure. In accordance with the invention, a party generates the Drffie- 

35 Hellman value p* and combines it with a function of at least the password using the so-called group operation, and 
transmits the resulting value to the other party. The group operation is defined for the particular group being used, and 
will be described in further detail below. For present purposes, It is sufficient to recognize that every group has a group 
operation and a corresponding inverse group operation. Upon receipt of the value, the other party performs the inverse 
group operation on the received value and the function of at least the password to extract p* such that the other party 

40 may then generate the shared secret p*y using fts knowledge of y The use of the group operation and the inverse 
group operation in conjunction with a Diffie-Hellman type key exchange protocol as descrfoed herein provides benefits 
over the prior art password-only mutual network authentication protocols. Perhaps most importantly, it provides a pro- 
tocol which can be proven to be secure against attacks by adversaries which have access to the communication 
channel. As described above, the Diffie-Hellman value p* is combined with a function of at least the password. The 

45 term "at least* is used because, in various embodiments, p* may be combined with a function of the password alone, 
or a function of the password along with identifiers of the parties to the protocol in order to ensure that the password 
is unique for any particular pair of parties. 

[0013] In accordance with one embodiment of the invention, the parties may authenticate each other by computing 
a function of at least certain parameters, transmitting the computed value to the other party, and then each party 
so checking the received value against its own computed value. The parameters used for the computation may be at least 
one of a party identifier, the Diffie-Hellman value (p* or gY), the shared secret, and the shared password. By computing 
a function of at least one of these values, the parties may authenticate that the other party is in possession of the 
shared password. 

[0014] In accordance with another embodiment of the invention, the parties do not explicitly authenticate each other, 
55 but instead the parties implicitly authenticate each other by each generating the shared secret key and using that 
generated shared secret key as a session key for communication. If either party is not in possession of the correct 
password, then that party would not be able to generate the correct secret session key and communication between 
the parties would not be possible. In accordance with this embodiment, both parties use the above described technique 
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of combining their Diffie-Heltman values with a function of at least the password using the group operation and trans- 
mitting the resulting value to the other party. Upon receipt of the value from the other party, each party extracts the 
other party's Diffle-Heilman value using the inverse group operation, and then computes the shared secret key. 
[0015] The two parties to the communication protocol will most often be a client computer and a server computer. 

5 In the above described embodiments, the client and server both store the shared password. In other embodiments of 
the invention, in order to protect against a security compromise at the server, the server is not in possession of the 
password, but instead is provided with, and stores, a so-called password verifier which, as described in further detail 
below, is a function of the password. The password itself cannot be determined from knowledge of the password verifier. 
The protocols in accordance with these embodiments of the invention are similar to the embodiments described above, 

10 except the password verifier is generally used in place of the actual password. However, since the server does not 
know the actual password, different techniques must be used by the two parties in order for each party to securely 
authenticate that the other party is actually in possession of the correct password verifier or actual password. In one 
embodiment, the parties authenticate each other using encryption based on the El Gamal encryption technique. 
[001 6] These and other advantages of the invention will be apparent to those of ordinary skill in the art by reference 

15 to the following detailed description and the accompanying drawings. 

Brief Description of the Drawings 
(00171 

20 

FIG. 1 shows the prior art Diffie-HeJlman key exchange protocol; 

FIG. 2 shows a communication protocol in accordance with an explicit authentication embodiment of the invention 
in which both parties possess a shared password; 

FIG. 3 shows a communication protocol in accordance with an implicit authentication embodiment of the invention 
25 in which both parties possess a shared password; 

FIG. 4 shows a communication protocol in accordance with an explicit authentication embodiment of the invention 
in which one party possesses a password and the other party possesses a password verifier; and 
FIG. 5 shows a communication protocol in accordance with another explicit authentication embodiment of the 
invention in which one party possesses a password and the other party possesses a password verifier. 

30 

Detailed Description 

[0018] Cryptography is a well known technique for providing secure communication between two parties. Prior to 
describing the various embodiments of the present invention, some background and basic terminology will be provided. 

35 [001 9] | nf ormally, a function f from asetStoasetTisa one-way function if f[x) is easy to compute for all x in S but 
for most y in 7, it is computationally infeasible to find any x in S where f{x) = y. One example of a one-way function is 
modular exponentiation. Let p be a large prime and g a generator of the multiplicative group mod p (that is, the numbers 
in the range 1 p-1). Then /(x)=o*mod p is generally assumed to be a one-way function. The inverse function, called 
the discrete log function, is difficult to compute. There are also other groups in which the discrete log function is difficult 

40 to compute, such as certain elliptic curve groups. 

[0020] Let Ac and /denote security parameters, where Arts the main security parameter and can be thought of as a 
general security parameter for hash functions and secret keys, and / > k can be through of as a security parameter for 
discrete-log-based public keys. Let {0,1}* denote the set of finite binary strings and {0,1 Y* the set of binary strings of 
length n. A real-valued function e(n) is negligible if for every C > 0, there exists nc> 0 such that e(n) < 1 / nC for all n>n c 

45 Let got size at least Ac and pof size /be primes such that p= rq+ 1 for some value r co-prime to q. Let o; be a generator 
of a subgroup of T of size q. Call this subgroup 6^, 

[0021 ] A key exchange protocol called Difne-Hellrnan Key Exchange and described in W. Diffie and M. Hellman, New 
Directions in Cryptography, IEEE Transactions on Information Theory, vol. 22, no. 6, 644-654, 1976, is based on the 
modular exponentiation function. Specifically, two parties A and B agree on a secret key in accordance with the protocol 

so described in conjunction with Rg. 1 . In step 102 A chooses a random xfrom the group Z q where = {0,1 oyt) (or 

simply the integers mod q). In step 1 04 A computes X=g*mod p. In step 1 06, A transmits Xto B. In step 1 08 B chooses 
a random /from In step 110 B computes Y= p? mod p and transmits V to A in 112. At this point, a shared secret 
g*y (i.e., a secret key) can be computed by both A and B. (Note that hereinbelow we may ignore the mod p notation 
for notational simplicity if it is clear that we are working in mod p.) Since X = g* was transmitted from A to B in step 

55 1 06, B can calculate the shared secret g** by computing XT in step 1 1 6. Similarly, since Y = p? was transmitted from 
B to A in step 112, A can calculate the shared secret g*y by computing Y* in step 114. The shared secret Scan now 
be used by A and B as a session key for secure communication. 

[0022] Diffie-Heltman key exchange can also be performed over other groups in which the discrete log function is 
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difficult to compute, such as certain elliptic curve groups. Groups are well known in the art, as described in I.N. Herstein, 
Topics in Algebra, 2 nd edition, John Wiley & Sons, New York, 1975, as follows. A nonempty set of elements G is said 
to form a group if in G there is defined a binary operation, called the product and denoted by., such that 

5 1 . a,bGG implies that abGG (closed). 

2. a,b,c,G G implies that a-(b-c) = (a*fr)«c (associative law). 

3. There exists an element eeG such that a e=e-a=a for all aeG (the existence of an identity element in G) 

4. For every aGG there exists an element a^GGsuch that a-a* 1 = a* 1 -a = e(the existence of inverses in G). 

w [0023] Thus, more generally, Diff ie-Hellman key exchange operates in a specific group where the secret keys x and 
y are indices to elements of the group. Thus, consider a group G with a group generator gEG and G=\g,gg,g>gg, 
g-g-g-g,-"} where . is the group operation. As examples, if the group operation . for G is multiplication, then G = {gf 1 ,o?, 
If the group operation . for G is addition, then G = {1 g,2g,3g,4g,—}. Since the present invention may be 
implemented using different groups, as used hereinbelow and in the claims, the notation g* means that the group 

is operation is applied x times on the group generator g. Further, for every group, there is also an inverse group operation 
represented herein as _. As used hereinbelow and in the claims, the inverse group operation is defined as follows. 
The inverse group operation on x and y, i.e. £, is defined as x/ 1 . 

[0024] A mutual authentication and key exchange protocol in accordance with a first embodiment of the invention is 
shown in Fig. 2. Steps shown on the left side of the figure are performed by a first party A, and steps shown on the 

20 right side of the figure are performed by a second party B. Typically, A will be a client machine and B will be a server 
machine. However, this is not required, and A and B are labeled as client and server respectively only as an example 
to show the typical case, but it is to be understood that the invention is not limited to the case where A and B are client 
and server, but instead the invention is applicable to any two parties A and B. Arrows represent communication between 
the parties. In accordance with the protocol, the server will authenticate itself to the client and the client will authenticate 

25 itself to the server. After both sides have authenticated, each will generate a secret session key which may be used 
for subsequent secure communication. 

[0025] Prior to initiation of the protocol it is assumed that the client and the server are in possession of a password 
ic which the client uses to authenticate with the server. 

[0026] It is noted that the following protocol authenticates both the server and the client. Thus, neither the server nor 
30 the client are assumed to be authentic, and thus either the server or the client may be an adversary. The client may 
be an adversary attempting to authenticate itself and gain access to the server. The server may be an adversary 
attempting to spoof another authentic server in an attempt to gain sensitive information from an unsuspecting client 
[0027] As would be readily apparent to one of ordinary skill in the art, the server and client may be implemented as 
programmed computers operating under control of computer program code. The computer program code would be 
35 stored in a computer readable medium (e.g. a memory) and the code would be executed by a processor of the computer. 
Given this disclosure of the invention, one skilled in the art could readily produce appropriate computer program code 
in order to implement the protocols described herein. The client and server communicate with each other via a data 
network. Such networked programmed computers are well known in the art and will not be described in further detail 
herein. 

40 [0028] Returning now to Fig. 2, in step 202 the client chooses a random value for the index xfrom Then, in step 
204 the client computes a parameter m as m = sfiH^ (AftJc)K mod p, where A is a unique identifier of the client, B is 
a unique identifier of the server, k is the client's password for this particular server, H, is a random hash function, and . 
represents the group operation. H A ( A B,n ) is raised to the r power in order to ensure that the result is within G^. 
Informally, a function /-/from a set S to a set Twill be called a random hash function if the output of H looks random 

45 or at least is unpredictable until the function is computed with an input x in a Since H A must output something that 
looks random in Z p , it should output Ipl+sec bits (where Ipt is the number of bits of p and sec is the security parameter. 
The security parameter may be, for example, 1 60. Known functions that generally behave this way are SHA- 1, described 
in FIPS 180-1, Secure Hash Standard, Federal Information Processing Standards Publication 180-1, 1995; and 
RIPEMD-1 60, described in H. Dobbertin, A. Bosselaers, B. Preneel, RIPEMD-160: a strengthened version ofRIPEMD, 

50 in Fast Software Encryption, 3rd Intl. Workshop, 71 -82, 1 996. 

[0029] The tuple (A f B 9 n) is used, rather than only the password, in order to ensure that it is unique for each client- 
server pair. The password alone is all that seems to be required for heuristic security, but, as discussed in further detail 
below, the client and server names seem to be necessary for a formal proof of security. Thus, in accordance with an 
aspect of the invention, a function of at least the password is combined with the Diffie-Hellman value g* by performing 

55 the group operation on the function of at least the password and the Diffie-Hellman value g*. This is an important step 
of the protocol as it ensures that the Diffie-Hellman value may only be extracted from the parameter m by someone 
who has knowledge of the password. This extraction of the Diffie-Hellman value p5 will be described in further detail 
below in conjunction with step 214. In step 206 the client transmits the parameter m to the server. 
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[0030] Upon receipt of the parameter m, the server tests the parameter value in step 208 to ensure that the value is 
not 0 mod p. if the value is 0 mod p, the server terminates the protocol because 0 is not in 2^. Otherwise, in step 210, 
the server chooses a random value for the index y from In step 212 the server assigns a parameter u, the Diffie- 
Hellman value p?. Next, in step 214, the server computes the Diffie-Hellman shared secret g*y (referred to as a in this 
5 protocol) using the received parameter m as follows: 

o-f ^ -J mod p. 

10 

We will now describe this step in further detail (leaving out the mod p notation for notational simplicity). First, it should 
be recalled that, as described above, for every group operation, there is an inverse group operation such that the 
inverse group operation on x and y, i.e. is defined as x-y 1 . Thus, one skilled in the art would recognize that the 
calculation of 

15 

m 

(H,(A,B,n)) r 

20 in step 214 is performing the inverse group operation on m and the function of at least the password. Substituting the 
value of m from step 204, we have 

g x .(H,(A,B,K)) r 

25 (H,{A,B,n)) r 

Thus, if the server has possession of the correct password n t then the server can extract the Diffie Hellman value p* 
from the value of the received parameter m. Thus, the computation in step 21 4 will result in the server generating the 
Diffie-Hellman shared secret g*>\ 
30 [0031] Next, in step 216, the server computes k = (A,B,m,[L,o,n) t where is another random hash function 
which must output sec bits, where sec is the security parameter. The parameter k will be used by the client A, as 
described below, to authenticate that the server is in possession of the correct password. In step 21 8 the server trans- 
mits parameters u. and xto the client. 

[0032] Upon receipt of parameters u. and k, the client computes a =u* mod p in step 220. Since u. = a* u* = g*y, 
35 which is the Diffie-Hellman shared secret In step 222 the client computes Ai> a (A,B,m,^<3 f n) using its own knowledge 
of jc and tests whether the result is equal to the parameter Ar received from the server in step 21 8. If they are the same, 
then the client has authenticated the server. If they are not the same, then the client terminates the protocol as the 
server has not authenticated itself. In step 224, the client computes k*=H 2b (AB,ro,u.,ovc) which will be used by the 
server to authenticate the client as described below. In step 226 the client generates session key Kas K= Hj {A,B,m, 
40 n r o,7i ). In step 228 the client transmits K to the server. Again, and Hj are random hash functions which must output 
sec bits, where sec is the security parameter. 

[0033] In step 230 the server computes H^A^m^o^) using its own knowledge of n and tests whether the result 
is equal to the parameter Af received from the client in step 228. If they are the same, then the server has authenticated 
the client If they are not the same, then the server terminates the protocol as the client has not authenticated itself. 
45 in step 232 the server generates session key /C as K=H 3 (A r B r m t \i J o > ^ ). 

[0034] At this point, both the client and server have authenticated with each other, and both the client and the server 
have generated the same secure session key K t which may be used for subsequent secure communication between 
the client and the server. 

[0035] A second embodiment of the invention will now be described in conjunction with Rg. 3. In this embodiment, 
so the authentication between the parties is implicit, which means that there are no steps taken by either party to explicitly 
authenticate the other party. Rather, each party attempts to generate the session key, but if either party does not have 
the appropriate password, then that party will be unable to generate the correct session key and communication be- 
tween the parties will not be possfole. Referring now to Rg. 3, steps 302 through 31 0 correspond to steps 202 through 
21 0 of Rg. 2. In step 31 2 the server computes parameter u. as u, = <p (H^ A, B f n)Y mod p, which is similar to step 204 
55 described above in conjunction with Rg. 2. As described above in conjunction with step 204, in effect, step 31 2 results 
in combining a function of at least the password with the Diffie-Hellman value <p by performing the group operation on 
the function of at least the password and the Drffie-Hellman value pr. 

[0036] Next, in step 314, the server extracts the Diffie-Hellman value p* and computes the Diffie-Hellman shared 
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secret g*y as described above in conjunction with step 21 4. In step 31 6, the server computes session key Kas K=H 3 
{A,B,m,\i,c,n). In step 318 the server transmits parameter u., generated in step 312, to the client 
[0037] Upon receipt of parameter u., in step 320 the client tests the parameter u. value to ensure that the value is not 
0 mod p. If the value is 0 mod p, the client terminates the protocol. Otherwise, in step 322, using the value of p., the 
5 client extracts the Diffie-Hellman value p* and computes the Diffie-Hellman shared secret g*y as described above. In 
step 324, the client computes session key Kas K=H z {A,B,m,\i,o,n ). 

[0038] At this point, both the client and the server have generated the session key K based on their knowledge of 
the password. If both the client and the server were in possession of the correct password, then both will have generated 
the same session key AC, which they may use for secure communication. However, if either one of the parties was not 
10 in possession of the correct password, then that party will not have generated the correct session key and communi- 
cation between the parties will not be possible. 

[0039] The protocols described in conjunction with Figs. 2 and 3 assumed that the server possessed and stored the 
password tc. One potential problem with such protocols is that a security compromise of server storage may allow an 
adversary to obtain the passwords of clients. In order to protect against such an occurrence, we now describe another 

'5 embodiment of the invention in which the server does not possess the password tc, but instead stores a so-called 
password verifier V. As used herein, a password verifier is a value which may be computed as a function of the pass- 
word, but the password cannot be determined from knowledge of the password verifier. In the embodiments described 
herein, the password verifier Vis a function of the password tc, where V= cf and v=H 0 (A f B,n) for a particular client A 
and server 0, where Hq is a random hash function which must output \cfi +sec bits. Since the client knows tc, the client 

20 can compute v=H 0 (A,B,n ) and then from v can compute the verifier V = cf. The server only knows V, and cannot 
compute v (which is the discrete log of V). The protocol in accordance with this embodiment of the invention is shown 
in Rg. 4. First, in step 401 , the client generates the password verifier V as described above. Steps 402 through 422 
then proceed as described above in conjunction with steps 202 through 222, except in steps 402 through 422 the 
password verifier V is substituted for the password tc. At this point, if the test in step 422 is true, then the client has 

25 authenticated that the server knows the correct password verifier Wand now the client must authenticate itself to the 
server by proving that it knows the correct password. 

[0040] In step 424 the client chooses a random value for the index cfrom The client computes a=g° in step 426 
and computes e=H(A,B,m,\i,o,a, V) in step 428. Next, in step 430, the client computes S=c-ev. In step 432 the client 
transmits Sand a to the server. Upon receipt of Sand a, in step 434 the server computes e=H(A f B,m,\i,o f a,V) using 

30 its knowledge of V. In step 436, the server computes p^v* If the value computed by the server in step 436 matches 
the value of a received from the client in step 432, then the server accepts the client as authentic. Finally, the client 
and the server compute the session key as AC= (A,B,m,\i,o,a,V) in steps 438 and 440 respectively. 
[0041] Intuitively, the test in step 436 will authenticate the client as follows. Referring to the server's calculation in 
step 436 of a = p*v* since V = <f t the computation in step 436 becomes a = cfdcfY = p^p^ = = p* because 

35 from step 430 it is seen that c=s -tev. Thus, if the server's computation of a matches the a received from the client in 
step 432, the server knows that the client has knowledge of v, which the client could have computed only with knowledge 
of the password tc. 

[0042] Another embodiment of the invention is shown in Rg. 5, which also shows a protocol in which the server does 
not possess the password tc, but instead stores a password verifier V. Steps 501 through 514 are the same as steps 
40 401 through 414 described above in conjunction with Rg. 4. In step 516, the server chooses a random cfrom 2^ and 
computes a as follows: 



45 



c <E r {0,1}*, a =g "° (AAc) mod p, 
where H Q is a random hash function, which must output ^ + sec bits. In step 518, the server computes 



*> k^c®H 2a (A.B.m.M.a^V"*^ mod p 9 v) > 

where 0 represents exclusive or (XOR). In step 520 the server transmits u.,a,Ar to the client Upon receipt of \L,aJc, the 
client computes o = u* mod p in step 522. At this point, the client and the server both possess the shared secret o. In 
55 step 524 the client computes c=k® (A,B,m,\L,a,o,a v , V) . In step 526 the cl ient computes p"o(4Ac) mo d p and tests 
whether the computed value is the same as the value of a received from the server in step 520. If they are not the 
same, then the server has not property authenticated itself with the client and the client terminates the protocol. If the 
computed a is the same as the value of a received from the server in step 520, then the client determines that the 
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server is authentic and continues with step 528 of the protocol and calculates kf= (A,B,m f \i,a,a, k,c, V). In step 530 
the client computes the session key K = tt> (AB,m,ii,a f c,V). In step 532 the client transmits k*to the server. In step 
534 the server computes {A,B,m,\L,o,a,k,c,V) and determines whether the computed value is the same as the Ac* 
value received from the client in step 532. If they are not the same, then the client has not authenticated itself with the 
5 server and the server terminates the protocol. If the computed k' is the same as the value of K received from the client 
in step 532, then the server determines that the client is authentic and continues with step 536 of the protocol and 
calculates the session key K= Hz(A,B,m,\Lfi,c,V). 

[0043] Intuitively, the authentication of the client and server is based on El Gamal encryption, which will be described 
only briefly here, but is described in further detail in T. EIGamal, A Public Key Cryptosystem and a Signature Scheme 

io Based on Discrete Logarithms, IEEE Transactions on Information Theory, IT-31 , 4, pp. 469-472, 1985. In general, a 
message M is encrypted in accordance with El Gamal encryption as E(M) = (fiT, jflM), where r is a random value, y is 
the public key, x istfie private key, and y = An encryption (A,S) is decrypted as D(A,B^. Substituting values, we 
have -^ x = X-£ = sQ± = M. Thus, in order to decrypt a message encrypted using the El Gamal technique, the secret 
key is^requffed. ln%second version of El Gamal encryption, a message M is encrypted as E(M) = (flr,HtyO©Af), where 

15 r is a random value, y is the public key, x is the private key, and y = An encryption (AS) is decrypted in accordance 
with this second technique as D(A,B) = H{A*)OB. Substituting values, we have H{A^®H{y^M = H<yy®Hiy)®M = M. 
Thus, once again, in order to decrypt a message encrypted using the El Gamal second technique, the secret key is 
required. 

[0044] Now we define a "self-certifying El Gamal encryption", in which the second version of El Gamal is used, but 
20 W fth r= H\M) t a random hash of the value being decrypted, instead of just a purely random value. Then when a party 
receives an encryption (AS) and decrypts it to get M, that party can test whether A = Note that every (AS) 
defines an encryption of something, but the self certification verifies that the encryptor knows exactly what was en- 
crypted, and thus what encryption key was being used. 

[0045] Referring now to the protocol shown in Fig. 5, one skilled in the art will recognize that steps 51 6 and 51 8 are 
25 performing a self-certifying El Gamal encryption, with the message being encrypted being a random value c, and where 
the public key is the password verifier V and the secret key is v. The encryption value is assigned to the parameter k 
In step 524 the client decrypts the encrypted k received from the server to extract c, and then performs the test of step 
526. If this test is true, then it certifies that the server is in possession of the correct password verifier V. In step 528 
the client uses the computed value of c to generate k 1 and transmits Jc'to the server in step 532. If the server's test in 
30 step 534 is true, then that certifies that the client is in possession of the correct v because only with the secret key v 
can the client perform the decryption and obtain the cthat is input to the hash function used in computing fc 
[0046] In yet other embodiments of the invention, the protocol shown in Figs. 2 may be modified such that the server 
does not store the password n, but instead stores the value (H,(AB,w)K. does not require any additional compu- 
tation and has the advantage that a naive user who uses it with two servers B, and fi^ is not trivially vulnerable on B^ 
35 if Bj is compromised. 

[0047] The inventors have proven that a mutual authentication and key exchange protocol in accordance with the 
present invention is secure. An outline of the intuition of the proof follows. Intuitively, we must prove: 

(1) Two parties that share a password and follow the protocol will authenticate each other and result with a long 
40 shared secret. 

(2) Assuming the Diffie-Hellman protocol is secure, our protocol is as secure as an "ideal-world protocol" with a 
trusted party, in which two honest parties can open connections to each other and have the trusted party generate 
a long shared secret for them to secure the connection, but in which an adversary may also query the trusted party 
for the shared password once per open connection (before it is secured). (Intuitively, this models the adversary 

45 making a random guess at a password and attempting to authenticate himself.) 

[0048] Part (1 ) is obvious from inspection of the protocol. 

[0049] Part (2) is more difficult We show that we can simulate the real protocol without knowing the passwords, but 
only using the trusted party in the ideal world, and such that an adversary attacking our simulation is indistinguishable 

so from an adversary attacking the real protocol in the real world. (This is a well-known cryptographic proof technique, 
the "multi-party simulatability" technique as described in D. Beaver, Secure Multiparty Protocols and Zero-Knowledge 
Proof Systems Tolerating a Faulty Minority, Journal of Cryptology, 4(2), pages 75-1 1 22, 1 991 .) 
[0050] Technically, our model assumes that all hash functions are completely random, and thus whenever the func- 
tions are used, the simulator may see the inputs, and set the outputs (as long as these outputs are set in a random way). 

55 [0051] The genera] idea of our simulator is to simply fake the long shared secrets between two honest parties com- 
municating to each other, and then to try to detect guesses on the password (by examining the adversary's hash 
function queries) on ail other conversations, turning them into "test password" queries to the trusted party. The difficult 
part of this is to show that the adversary may not make more than one password guess per open connection. To show 
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this, we show that if the adversary could, then we could solve the Diffie-Hellman problem. (Specifically, we could take 
values X, XZGG, with X= g*, and Y=& (for unknown xand y) and determine whether Z= 

[0052] The foregoing Detailed Description is to be understood as being in every respect illustrative and exemplary, 
but not restrictive, and the scope of the invention disclosed herein is not to be determined from the Detailed Description, 

s but rather from the claims as interpreted according to the full breadth perm rtted by the patent laws. It is to be understood 
that the embodiments shown and described herein are only illustrative of the principles of the present invention and 
that various modifications may be implemented by those skilled in the art without departing from the scope of the 
invention. For example, in the protocols described above, certain parameters are used in evaluating the hash functions. 
It is noted that not all of the parameters are required for heuristic security, but the additional parameters allow the 

10 protocols to be formally proven secure. For example, steps 21 6, 222, 224, 230, 226 and 232 of the protocol shown in 
Fig. 2, steps 316 and 324 of the protocol shown in Rg. 3, steps 416, 422, 438 and 440 of the protocol shown in Fig. 
4, and steps 530 and 536 of the protocol shown in Rg 5 seem to require only the parameter a in the hash functions to 
make the protocol heuristicalfy secure. However, the use of the additional parameters shown and described above 
allows the protocols to be formally proven secure. Similarly, steps 428 and 434 of the protocol shown in Rg. 4 seem 
to require only the parameters o and a in the hash functions to make the protocol heuristicaily secure. However, the 
use of the additional parameters shown and described above allows the protocol to be formally proven secure. Similarly, 
steps 518 and 524 of the protocol shown in Rg. 5 seem to require only the parameters a, a, and 

to make the protocol heuristicaily secure. However, the use of the additional parameters shown and described above 
allows the protocol to be formally proven secure. Rnalry, steps 528 and 534 of the protocol shown in Rg. 5 seem to 
require only the parameters a and c in the hash functions to make the protocol heuristicaily secure. However, once 
25 again, the use of the additional parameters shown and described above allows the protocol to be formally proven 
secure. 



Claims 

30 

1 . A method for communication via a data network, between two parties that share a password , using a Diffie-Hellman 
type key exchange on a particular group to generate a shared secret g*y, where g is the group generator known 
to both parties and x is an index known to one party and y is an index known to the other party, said group having 
a group operation and an inverse group operation, said method comprising the steps of: 

35 one party generating a parameter m by performing the group operation on g* and a function of at least said 

password, and transmitting m to the other party, whereby the other party may perform the inverse group operation 
on m and said function of at least said password to extract p» and further calculate said shared secret g*y. 

2. The method of claim 1 wherein said one party is a client and said other party is a server. 

40 

3. The method of claim 1 further comprising the step of: 

said one party receiving p? from said other party and generating said shared secret p*x. 

4. The method of claim 3 further comprising the step of: 

45 said one party authenticating said other party by comparing a received value against a function of at least 

one of an identifier of said one party, an identifier of said other party, m, <p, the shared secret, and the password. 

5. The method of claim 3 further comprising the step of: 

said one party transmitting a function of at least one of an identifier of said one party, an identifier of said 
so other party m, pr, the shared secret, and the password, to said other party whereby the other party may authenticate 

said one party. 

6. The method of claim 3 further comprising the step of : 

said one party generating a session key as a function of a least one of an identifier of said one party, an 
55 identifier of said other party, m, <p, the shared secret, and the password. 

7. The method of claim 1 further comprising the steps of: 
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10 



said one party receiving a parameter \i from said other party where u, was calculated by the other party by 
performing the group operation on p* and a function of at least the password; 

said one party performing the inverse group operation on u. and said function of at least the password to extract 
o*; and 

said one party calculating said shared secret pv. 

The method of claim 7 further comprising the step of: 

said one party generating a session key as a function of at least one of an identifier of said one party, an 
identifier of said other party, m, u., the shared secret, and the password. 



9. A method for communication between two parties over a data network using a Drffie-Hellman type key exchange 
on a particular group to generate a shared secret g*y, where p is the group generator known to both parties, x is 
an index known to one party, and y is an index known to the other party, said group having a group operation and 
an inverse group operation, said method comprising the steps of: 
is one party generating a parameter m by performing the group operation on p* and a function of at least a 

password verifier, and transmitting m to the other party, whereby the other party may perform the inverse group 
operation on m and said function of at least said password verifier to extract p* and further calculate said shared 
secret g*y. 

20 10. The method of claim 9 wherein said one party is a client and said other party is a server. 

11 . The method of claim 9 further comprising the steps of: 

said one party receiving p? from said other party and generating said shared secret p^. 

25 1 2. The method of claim 1 1 further comprising the step of: 

said one party authenticating said other party by comparing a received value against a function of at least 
one of an identifier of said one party, an identifier of said other party, m, pv, the shared secret, and the password 
verifier. 

30 13. The method of claim 1 2 further comprising the steps of: 

said one party computing p* where c is an index known to said one party; 

said one party computing a parameter e as a function of at least p° and at least one of an identifier of said one 
party, an identifier of said other party, m, pr, the shared secret, and the password verifier; 
35 said one party computing a parameter S as S = c - ev, where v is the discrete log of the password verifier; and 

said one party transmitting S and p° to said other party, 

whereby said other party may authenticate said first party based at least in part on said values of S and p°. 

14. The method of claim 13 further comprising the step of: 

40 said one party generating a session key as a function of a least one of an identifier of said one party, an 

identifier of said other party; m, pr, the shared secret, p° and the password verifier. 

15. The method of claim 11 further comprising the step of: 

said one party transmitting a function of at least one of an identifier of said one party, an identifier of said 
45 other party, m, pr r the shared secret, said random value, and the password verifier to said other party whereby the 
other party may authenticate said one party. 

16. The method of claim 11 further comprising the steps of: 

said one party authenticating said other party based on self-certifying El Gamal encryption in which a random 
so value is encrypted using the password verifier as the public key and the discrete log of the password verifier as 

the secret key. 

17. The method of claim 16 further comprising the step of: 

said one party generating a session key as a function of a least one of an identifier of said one party, an 
» identifier of said other party, m, p/ t the shared secret, said random value, and the password verifier. 

1 8. A method for communication via a data network, between two parties that share a password , using a Drffie-He llman 
type key exchange on a particular group to generate a shared secret p*?, where p is the group generator known 
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to both parties and y is an index known to one party and x is an index known to the other party, said group having 
a group operation and an inverse group operation, said method comprising the steps of: 

said one party receiving a parameter m from said other party, where m was computed by the other party by 
5 performing the group operation on and a function of at least said password; and 

said one party performing the inverse group operation on m and said function of at least said password to 
extract g* and further calculate said shared secret gP. 

19. The method of claim 1 8 wherein said one party stores said password. 

10 

20. The method of claim 18 wherein said one party stores a value which represents said function of at least said 
password but said one party does not store said password. 

21 . The method of claim 1 8 wherein said one party is a server and said other party is a client. 

15 

22. The method of claim 1 8 further comprising the step of: 

said one party transmitting to said other party a function of at least one of an identifier of said one party, an 
identifier of said other party, m, the shared secret, and the password. 

20 23. The method of claim 1 8 further comprising the step of: 

said one party authenticating said other party by comparing a received value against a function of at least 
one of an identifier of said one party, an identifier of said other party, m, (p, the shared secret, and the password. 

24. The method of claim 1 8 further comprising the step of: 

25 said one party generating a session key as a function of a least one of an identifier of said one party, an 

identifier of said other party, m, the shared secret, and the password. 

25. The method of claim 1 8 further comprising the step of: 

said one party generating a parameter u. by performing the group operation on <p and a function of at least 
30 said password, and transmitting u. to the other party, whereby the other party may perform the inverse group 

operation on u. and said function of at least said password to extract & and further calculate said shared secret eft. 

26. A method for communication between two parties over a data network using a Diffie-Hellman type key exchange 
on a particular group to generate a shared secret g*y, where g is the group generator known to both parties, y is 

35 an index known to one party, and x is an index known to the other party, said group having a group operation and 

an inverse group operation, said method comprising the steps of: 

said one party receiving a parameter m from said other party, where m was computed by the other party by 
performing the group operation on p* and a function of at least a password verifier, and 
40 said one party performing the inverse group operation on m and said fu notion of at least said password verifier 

to extract g* and further calculate said shared secret 

27. The method of claim 26 wherein said one party is a server and said other party is a client 

45 28. The method of claim 26 further comprising the step of: 

said one party transmitting to said other party a function of at least one of an identifier of said one party, an 
identifier of said other party, m, the shared secret, and the password verifier 

29. The method of claim 26 further comprising the steps of: 

50 

said one party authenticating said other party based at least in part on values of parameters Sand gf received 

from said other party, 

wherein, 

c is a random value; 

55 S = c-ev, where v is the discrete log of the password verifier, and 

e is a function of at least <f and at least one of an identifier of said one party, an identifier of said other party, 
m, <p, the shared secret, and the password verifier. 
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30. The method of claim 29 further comprising the step of: 

said one party generating a session key as a function of a least one of an identifier of said one party, an 
identifier of said other party, m, & t the shared secret, & and the password verifier. 

5 31 . The method of claim 26 further comprising the steps of: 

said one party encrypting a random value using self-certifying El Gamal encryption using the password verifier 
as the public key and the discrete log of the password verifier as the secret key; and 
transmitting said encrypted random value to said other party. 

10 

32. The method of claim 26 further comprising the step of: 

said one party authenticating said other party based on a received value which was computed by said other 
party as a function of at least one of an identifier of said one party, an identifier of said other party, m, <p, the shared 
secret, said random value, and the password verifier. 

15 

33. The method of claim 26 further comprising the step of: 

said one party generating a session key as a function of a least one of an identifier of said one party, an 
identifier of said other party, m, eft, the shared secret, said random value, and the password verifier. 

20 



25 



30 



35 



40 



50 



55 



12 



EP1 134 929 A1 



FIG, 1 

(PRIOR ART) 



B 



X£ R Zq 



V 



X= g x mod p ^ 



102 



104 
106 



114 



S= Y x mod p 



112 



YCpZq 



If 



Y= g^mod p ^ 
S= XVmod p V 



108 



110 



116 



13 



EP1 134929 A1 



FIG. 2 
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FIG. 3 
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FIG. 4 
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FIG. S 



A CUENT 



B SERVER 



V= [A,B]= H 0 [A,B^ 




1^501 


V= g 2 






xe R Zq 






m= g x -(HXA,B,V)f mod p ' 



-504 
m 



506 



TEST m*0 mod p 



V 



508 



Y€ R Zq 



fi=qt mod p 



510 



512 



514 



C€ R jU t l| K ,a=g H o {A ' B ' C) mod 



i If 

a- mod p ' 



/ 52 ° 
522 



K=C®H 2o (* t B,m^o,ct v"^ 8,0 ) mod p.V 



516 



518 



c=k®h 2q (a > m^,o.<wi!v)K 



TEST aig^^ mod 



V 



K'= H 2o (A,B,m^V) 



1/ 



K = H 3 (A.B.m^i.gfiV) 



524 



526 



528 



530 



532 



TEST J^H^f^m, , aUV) 



1^534 



K = H 3 (A,B,m^a^V) 



r536 



17 



EP1 134 929 A1 
EUROPEAN SEARCH REPORT 



Application NmsAmf 

EP 00 30 9331 



DOCUMENTS COM9»ERH> TO BE RELEVANT 




Category 


CMfcn«ldocumwitw»i>idtaaDii,«*>i»"^»P**»; 


tocMm 


CXASSWCATXWOFTHE 
APFUGtfTION 0nt<&7) 


V 
A 


EP 0 977 396 A (LUCENT TECHNOLOGIES INC) 
2 February 2000 (2000-02-02) 

* column 3, line 42 - line 45 • 1 

* column 4, line 56 - column 5, line 49 * 

* column 6, line 46 - line 57 ♦ 


i 

»,5 




H04L9/08 


D,X 


JABL0N D P: * STRONG PASSWORD-ONLY 

AUTHENTICATED KEY EXCHANGE" 

COMPUTER COMMUNICATIONS 

REVIEM.US.ASSOCIATION FOR COMPUTING 

MACHINERY. NEW YORK, 

vol. 26, no. 5, • 

1 October 1996 (1996-10-01), pages 5-26, 

XP00064196B 

ISSN: 0146-4833 

* page 19, line 1 - line 14 * 


I 






A 


US 5 953 420 A (NATYAS JR STEPHEN MICHAEL 
ET AL) 14 September 1999 (1999-09-14) 

* abstract * 

* column 5, line 1 - column 6, line 7 * 


6,8,24 












A 
A 


JABLON 0 P: "EXTENDED PASSWORD KEY 
EXCHANGE PROTOCOLS IMMUNE TO DICTIONARY 
ATTACK" 

PROCEEDINGS. IEEE INTERNATIONAL HUKKiWJri 
ON ENABLING TECHNOLOGIES: INFRASTRUCTURE 
FOR COLLABORATIVE EMTERPRISES,XX t XX, 
18 June 1997 (1997-06-18), pages 248-255, 
XP000986630 

* abstract * 

* page 248, right-hand column, line 14 - 
line 15 ♦ 

* page 250, left-hand coluam, last 
paragraph - right-hand column, paragraph 
15 * 

* page 251, left-hand column, line 16 - 
line 30 * 


9,26 
1,18 


H04L 

i 




Trie praam mmdtx report has bttn dram up far at! ctokrw 








pCSSS I ft»cfuuM*« if— * 

I THE HAGUE 1 27 June 2001 


Helper, 6 


| CATEGORY OF CITED DOCIAJEMTS T ;^^*^t?,S 


ikwonfen 
itarwdoruor 


5 A:te 

] Om 

8 P:,n 


3f>— vmrumn www .. - * 

- - .-t.^.niMnt uuMlWnl 

pnniiMaDninwi 


tam»pal»rtffvi%.corr«ponclna 



18 



EP 1 134,929 A1 



ANNEX TO THE EUROPEAN SEARCH REPORT 
ON EUROPEAN PATOfT APPLICATION NO. 



EP 00 30 9331 



Tnta annc Hats tt>» patent temtty rneirfceiuietalh y to t^pa^doeumanta cfted In trr gbove-mfrflooad Euopoan search report. 
art- as con Urfnvd In tha European Patent 



The 
The 



Patent OffWv Is In no way 



lor thiw paytlcutere which are nws^y oj^on for tie ptvpcee of Woftnatton. 

27-06-2001 



Patent document 
Jtodtafl 



Publication 



Patent ta mtty 
memberts) 



Publication 
dale 



EP 0977396 A 02-02-2000 



US 6192474 B 
CN 1247423 A 
JP 2000078124 A 



20-02-2001 
15-03-2000 
14-O3-2000 



US 5953420 A 14-09-1999 



NONE 



' Former* 



about tMiamx:saeCmeMJaiBi«l of 0»EuiDpwn 



19 



